Skip to content

[DEVOPS] Deprecation warning wrapper for dict-like object renamed keys #2530

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

echedey-ls
Copy link
Contributor

@echedey-ls echedey-ls commented Aug 8, 2025

  • Partially helps with Add "poa_" prefix to return_components=True transposition model outputs #2529 (see for other relevant comments, in pvlib threads)
  • I am familiar with the contributing guidelines
  • Tests added
  • Updates entries in docs/sphinx/source/reference for API changes.
  • Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
  • New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
  • Pull request is nearly complete and ready for detailed review.
  • Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

Threatening my mail inbox again, duh? Just kidding.

But let's give us the opportunity to make the renaming of all and any keys in returned dictionaries and dataframes be not a super, duper, user-angering, developer-exhausting, breaking change.

Key changes that come with this PR:

  • A generator function of wrappers to apply to dict-like objects.
  • A bunch of tests that, if you feel can be improved, please go ahead.
  • A new contributing section, Python-proficient-contributors oriented, with the pvlib._deprecation functions listing. I've named it devops for now.

I understand if there are objections to the new doc page. Suggestions, like whole removal, etc welcome. Just wanted to propose making the docstrings the first place to check, rather than finding past or current uses to see how to use the utilities in that deprecation submodule. I was unsure of the best fit for that, so in the contributing section it went..

Regarding, the new func / wrapper, I doubt there are no doubts. Let me know any objections, concerns, or ways to improve either the implementation or the tests, not covered by the documentation.

As always, a friendly proposal. If you want, I can also add an example of how this would look like for #2529 (quick search didn't give any useful results of other issues that may benefit from this).

Handy links for every1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant